CRA a know-how producenta w sektorze kolejowym

Współczesny pojazd kolejowy, podobnie jak wiele komponentów wykorzystywanych przy jego produkcji, jest w coraz większym stopniu systemem elektronicznym i informatycznym. Systemy te i podzespoły tworzą rozbudowaną architekturę cyfrową pojazdu, w ramach której komunikują się ze sobą, z innymi urządzeniami i często również z sieciami zewnętrznymi. W konsekwencji zarówno pojazdy kolejowe, jak i część ich komponentów mogą stanowić tzw. „produkty z elementami cyfrowymi” w rozumieniu rozporządzenia (UE) 2024/2847 – Cyber Resilience Act („CRA”), którego część przepisów dotyczących poważnych incydentów wejdzie w życie 11 września 2026 r.

CRA dokłada do regulacji kolejowych kolejną warstwę wymagań w zakresie cyberbezpieczeństwa na etapie projektowania, rozwoju i produkcji oraz obsługi podatności produktów cyfrowych przez dany okres wsparcia. Co istotne, okres wsparcia nie musi być zrównany z całemu okresowi eksploatacji pojazdu, co oznacza, że mimo, iż pojazd kolejowy może być używany przez kilkadziesiąt lat, jego poszczególne komponenty mogą mieć własne okresy używania i wsparcia.

Znaczenie CRA dla producentów

Dla producentów szczególnie istotne jest jednak to, co nowe obowiązki oznaczają dla dokumentacji technicznej pojazdu przekazywanej dysponentowi i know-how. W procesie projektowania pojazdu i jego komponentów powstają bowiem schematy, opisy architektury, specyfikacje interfejsów, dane diagnostyczne, dokumentacja oprogramowania czy analizy ryzyka. Część z tych materiałów może stanowić istotne know-how producenta i jednocześnie mogą być one konieczne w przyszłości w procesie utrzymania, naprawy lub modernizacji taboru i w trakcie okresu wsparcia danego urządzenia.

W związku z tym powstaje napięcie między ochroną technologii producenta a dostępem do informacji potrzebnych innym uczestnikom rynku, a CRA tego napięcia nie rozwiązuje, ale wyraźnie je uwypukla.

SBOM

W pierwszej kolejności trzeba wskazać, że CRA sam w sobie nie ustanawia generalnego obowiązku przekazywania klientowi know-how ani pełnej dokumentacji konstrukcyjnej. Jednakże jego podstawowym obowiązkiem jest tzw. obowiązek SBOM (ang. Software Bill of Materials), co oznacza, że producent musi identyfikować i dokumentować komponenty znajdujące się w produkcie, m.in. poprzez sporządzenie SBOM, ale nie musi automatycznie wydawać go użytkownikowi. Załącznik II pkt 9 CRA przewiduje informację o miejscu dostępu do SBOM dopiero wtedy, gdy producent zdecyduje się go udostępnić.

Inaczej wygląda sytuacja wobec organów nadzoru rynku. Dokumentacja techniczna ma pozostawać do ich dyspozycji, a SBOM może zostać przekazany na uzasadniony wniosek, jeżeli jest to konieczne do weryfikacji zgodności. CRA odróżnia więc obowiązek posiadania informacji od obowiązku ich publikowania lub przekazania kontrahentowi.

Rozporządzenie nakazuje także tworzenie dokumentacji technicznej produktów z elementami cyfrowymi. Dokumentacja ta ma pozwalać wykazać zgodność produktu z wymaganiami cyberbezpieczeństwa i w stosownych przypadkach obejmować opis architektury systemu oraz relacji między komponentami. Nie oznacza to jednak generalnego obowiązku ujawniania pełnego kodu źródłowego, a dodatkowo Rozporządzenie przewiduje ochronę prawa własności intelektualnej, poufnych informacji handlowych i tajemnicy przedsiębiorstwa, w tym kodu źródłowego.

Problem pojawia się gdzie indziej – jeżeli bowiem aktualizacja, rekonfiguracja lub dostęp diagnostyczny wymagają autoryzacji producenta, mechanizm służący cyberbezpieczeństwu może jednocześnie wpływać na zakres czynności dostępnych dla późniejszego wykonawcy utrzymania. Kiedy zatem taka kontrola jest uzasadnionym środkiem bezpieczeństwa, a kiedy zakres dostępu powinien wynikać również z innych przepisów lub uprawnień podmiotu odpowiedzialnego za utrzymanie pojazdu?

Wymagania z Załącznika I do CRA

Załącznik I CRA wymaga m.in. możliwości bezpiecznego usuwania podatności, ochrony przed nieuprawnionym dostępem oraz ochrony integralności danych. CRA nie nakazuje wprost stosowania kryptograficznie podpisanego firmware ani nie przesądza, kto powinien posiadać klucze pozwalające autoryzować aktualizacje. Takie rozwiązania mogą jednak być jednym ze sposobów realizacji wymagań bezpieczeństwa.

Podobny problem dotyczy zarządzania podatnościami. CRA nakłada w tym zakresie odpowiedzialność na producenta i wymaga wskazania punktu kontaktowego dla ich zgłaszania. Nie czyni to producenta jedynym dopuszczalnym wykonawcą każdej późniejszej ingerencji w oprogramowanie, ale rodzi wątpliwości co do skutków zmian dokonywanych poza jego procesem: czy wpływają one na zgodność produktu i kto przejmuje odpowiedzialność za cyberbezpieczeństwo.

Osobny problem dotyczy producenta kompletnego pojazdu. Poszczególne komponenty mogą bowiem pochodzić od wyspecjalizowanych dostawców, którzy odpowiadają za własne produkty, a producent pojazdu odpowiada za ich integrację. W tym kontekście szczególną wartość ma nie tyle dokumentacja pojedynczego komponentu, ale wiedza o architekturze całego pojazdu, sposobie komunikacji podsystemów, interfejsach i logice ich integracji. Dokumentacja określonego komponentu nie oznacza jeszcze bowiem dostępu do wiedzy o jego integracji w konkretnym pojeździe i jednocześnie nie każda informacja dotycząca interfejsu lub integracji może być skutecznie zatrzymana wyłącznie jako know-how producenta.

Pojęcie istotnej modyfikacji

Znaczenie tej kwestii widać zwłaszcza przy modyfikacji produktu. CRA definiuje istotną modyfikację jako zmianę produktu dokonaną po jego wprowadzeniu na rynek, która wpływa na zgodność z zasadniczymi wymaganiami cyberbezpieczeństwa albo prowadzi do zmiany zamierzonego zastosowania. Art. 22 CRA przewiduje, że podmiot dokonujący takiej modyfikacji może zostać objęty obowiązkami producenta. W branży kolejowy ta kwestia jest szczególnie istotna – czas użytkowania pojazdu kolejowego wynosi średnio 20 do 30 lat i w tym czasie konieczna może być zmiana oprogramowania czy też dużo bardziej zaawansowane procesy modernizacyjne. Podmiot dokonujący zmiany może potrzebować dokumentacji pozwalającej ocenić jej wpływ na cyberbezpieczeństwo, podczas gdy pierwotny producent może uznać, że część żądanych materiałów obejmuje chronione know-how. Nie każda zmiana będzie jednak automatycznie istotną modyfikacją. Kluczowe są jej rzeczywiste skutki techniczne dla zgodności z CRA i zamierzonego zastosowania produktu. Dla uczestników rynku zasadnicze pytanie brzmi więc: co zostało zmienione, jaki jest wpływ tej zmiany na cyberbezpieczeństwo i kto przejmuje związane z nią obowiązki.

Istotnym wątkiem w ramach CRA jest dodatkowo wyłączenie z jej przepisów części zamiennych udostępnianych w celu wymiany identycznych komponentów produktów z elementami cyfrowymi, które są wytwarzane zgodnie z tymi samymi specyfikacjami co wymieniane komponenty. Wprowadzenie tego wyłączenia oznacza bowiem, że stosowanie tego wyjątku może zależeć od dostępu do specyfikacji pozostającej u pierwotnego producenta. CRA sam nie tworzy bowiem prawa do uzyskania takiej dokumentacji, ale nie przesądza też, że każda alternatywna część automatycznie prowadzi do istotnej modyfikacji.

Istotna pozostaje też procedura oceny zgodności właściwa dla produktu. Trzeba także oddzielić obowiązek zgodności z CRA od obowiązku udziału jednostki notyfikowanej. Rozporządzenie przewiduje bowiem różne obowiązki dla określonych produktów w zależności od tego, do jakiej kategorii związanej z utrzymaniem cyberbezpieczeństwa zostaną przypisane, przy czym produkty określone jako ważne lub krytyczne podlegają szczególnym regułom. W pierwszej kolejności istotne jest zatem skategoryzowanie danego produktu i dopiero wtedy można ocenić, jak duże znaczenie ma dostępność jednostek oceniających zgodność.

Dla znacznej części elektroniki i oprogramowania stosowanych w pojazdach kolejowych udział jednostki zewnętrznej może okazać się w ogóle niepotrzebny i samocertyfikacja będzie wystarczająca. Co jednak ważne, brak konieczności udziału jednostki zewnętrznej nie oznacza braku obowiązków CRA – obowiązki raportowania wykorzystywania podatności zaczynają być stosowane od 11 września 2026 r., a zasadnicze obowiązki producenta – 11 grudnia 2027 r.

Relacja CRA z obowiązkami ECM

Podkreślenia wymaga również fakt, że w ramach sektora kolejowego istnieje już system regulacji bezpieczeństwa i utrzymania, określony m.in. w ramach Rozporządzenia wykonawczego (UE) 2019/779 dedykowany głównie ECM, który przewiduje zarządzanie dokumentacją utrzymaniową i przepływem informacji. Dodatkowo obowiązują także przepisy dotyczące interoperacyjności i TSI, ustanawiające wymagania dotyczące podsystemów, pojazdów i określonych interfejsów. Regulacje te należy stosować zatem jednocześnie pamiętając, że przepisy CRA, w tym m.in. ochrona know-how na podstawie CRA nie mogą wyłączyć obowiązku udostępnienia lub standaryzacji informacji wynikającego z innych obowiązujących regulacji.

Poza regulacjami CRA dotyczącymi konieczności utrzymywania cyberbezpieczeństwa należy mieć także na uwadze prawo konkurencji. Samo bowiem posiadanie dokumentacji technicznej, praw własności intelektualnej czy tajemnicy przedsiębiorstwa nie oznacza obowiązku udostępniania ich konkurentom. Sytuacja staje się jednak bardziej złożona, gdy określona informacja lub dostęp techniczny pozostają pod wyłączną kontrolą producenta, a wykonywanie bez nich usług utrzymania, naprawy lub modernizacji jest w praktyce niemożliwe.
 
W określonych przypadkach może to wymagać analizy z perspektywy zakazu nadużywania pozycji dominującej, określonego w art. 102 TFUE. Granica ochrony know-how może zależeć więc od tego, które informacje należą do chronionego rdzenia technologicznego, a które – z uwagi na prawo kolejowe, interoperacyjność lub charakter prac – mogą wymagać szerszego dostępu. Ta sama dokumentacja może być także odmiennie oceniana przez samych uczestników rynku. Z perspektywy producenta istotne jest pogodzenie wymagań dotyczących cyberbezpieczeństwa, dokumentacji i aktualizacji i kontroli dostępu z ochroną know-how przedsiębiorstwa. Z punktu widzenia właściciela taboru lub wykonawcy utrzymania istotne jest natomiast ustalenie, czy odmowa dostępu do dokumentacji, danych diagnostycznych i możliwości dokonania zmiany znajduje już oparcie w wymaganiach cyberbezpieczeństwa i ochronie know-how, czy też inne podstawy prawne uzasadniają odpowiedni zakres dostępu. Odpowiedzi nie da samo oznaczenie dokumentu jako „confidential” ani samo powołanie się na CRA. Trzeba ustalić, czego dotyczy konkretna informacja, kto jej potrzebuje, w jakim celu oraz jakie regulacje znajdują zastosowanie.

Podsumowując należy stwierdzić, że CRA nie daje producentowi uniwersalnej „tarczy”, pozwalającej zatrzymać każdą informację ani wykonawcy utrzymania automatycznego prawa do dokumentacji producenta. Najciekawsze problemy zaczynają się tam, gdzie cyberbezpieczeństwo, ochrona know-how i potrzeby rynku utrzymania spotykają się w konkretnym stanie faktycznym podczas np. produkcji nowego typu pojazdu lub podczas przeglądu P4/P5.